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INTRODUCTION 



I . 

There is little doubt that the impact of the computer age 
has affected many in society. We are being flooded with new 
complex computer systems in which acquiring and retaining 
information has become increasingly difficult. The 
technological innovations in the computer field have created 
problems for both system designers and educators . System 
designers are faced with the dilemma of trying to create user- 
friendly interfaces for these new systems, while educators 
must find ways of teaching complicated information to 
potential users. 

The materialization of these problems has led to much 
attention being paid recently to the field of user interface 
design. No longer is it important to just design systems that 
meet the market demand, but systems must be designed and 
presented so that it is alluring to the user. As such, the 
human- factors issue plays an enormous role in the design of 
new computer systems . 

Along with the emergence of new systems, software that 
takes advantage of advanced technology must also be written 
and documented. When carefully developed, documentation can 
be used as a supplemental effort to ease the transition and 
enhance the relationship between user and machine 
[Schneiderman, 1986] . 
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Another contributor to the dilemma created by new computer 
production is the system comprehension issue. As hardware 
becomes more complex, technical manuals have become 
increasingly voluminous to accommodate pertinent facts. While 
enormous amounts of this information become available, more 
efficient ways of absorbing its content must be developed. 
Newly developed teaching aids must now encompass the technical 
sophistication of computer systems in addition to addressing 
the human -computer interface issues [Bradford, 1983] . Also, 
training must address a more diverse audience that is not only 
made up of data processing professionals but also clerical 
workers and managers. One way to meet these disparate needs 
is to create user documentation that can be used by the 
different levels of users and incorporate them into the 
learning process. 

A. PROBLEM BACKGROUND AND DEFINITION 

This is the age of the microcomputer. As microcomputers 
continue to grow in numbers and use, so does the need for 
communication among them. Spurred by the need to share 
hardware, software, and data, local area networks (LANs) are 
expected to proliferate in this environment [Sachs, 1985] . 

Many offices are now sharing their computer resources 
through networks, but even in small non-networked office 
environments, the potential for sharing computer resources is 
present and the move towards distributed systems is 
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inevitable. This prediction is based on the assumption that 
most personal computers do not operate in offices alone. In 
some cases, programs and data in offices are shared among 
machines and users via the exchanging of disks. Normally as 
an organization grows, so does its need for more powerful 
computers, larger storage devices, more memory, increased 
efficiency in the retrieval and update of data and more 
sophisticated peripheral devices [Luhn, 1985] . For 
organizations who want to cut costs, one solution is to share 
their equipment [Derfler, 1986] . This cost-cutting objective 
can be achieved through the use of computer networks. 

Networks offer an effective, efficient way to share 
applications and other resources. However, users need to be 
able to operate the software applications and access shared 
hardware resources such as printers in this type of 
environment. To meet these demands, adequate documentation 
and training must be available. 

Network training must be directed toward students, 
clerical workers, managers, and other users of the computers. 
These target audiences have varied levels of computer 
knowledge and experience, and often possess conflicting goals 
and expectations. Often, user documentation is developed 
without regard for the audiences' needs. Since not all users 
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encompassing system documentation is created, intended to meet 
all the information needs of all the system users. As a 
result, diverse audiences find the single "system manual" 
contains the wrong kinds and levels of information [Chinell, 
1990] . 

This thesis analyzes the functional and design issues 
associated with the development of software user documentation 
for one of these audiences, the information systems and 
management students of the Naval Postgraduate School, and 
produces reference guides for two applications software 
programs, WordPerfect 5.1 and dBase IV 1.1, as an end product. 
The study is a report of the developmental process used to 
design reference guides for applications software used in the 
Administrative Sciences/Information Systems computer networks 
at the Naval Postgraduate School. 

B. OBJECTIVES 

The primary objective of this project was to develop 
software user documentation for two applications programs 
resident in the networks (excluding the Apple networks) in the 
Administrative Sciences and Information Systems computer 
laboratories which would be used and understood by users of 
these laboratories. 
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C. THE RESEARCH QUESTION 

What is the most effective method for development of 
software documentation which will promote maximized use and 
enable greater productivity of the Administrative 
Sciences/Information Systems (AS/IS) computer laboratories for 
Naval Postgraduate management and information systems 
students? 

D . SCOPE 

The many problems associated with designing user 
documentation are the variables upon which this paper focuses. 
The intent of this study was to investigate the variables 
needed to produce effective software documentation for users 
of the AS/IS laboratories. These variables were tested to 
determine their effectiveness, and modifications then made 
based on users' needs and recommendations. 

1 . Audience Description 

These reference guides were designed to address an 
audience that represents an older-than-average college 
graduate student. Most of these students have been trained in 
some technical or managerial area in which they have been 
working for a number of years. Most will be pursuing advanced 
degrees in the administrative, managerial science, or 
information systems area, and have limited amounts of free 
time available because of constraints that course requirements 
place on them. Computer familiarity varies immensely, with 
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experience ranging from the novice to the dedicated computer 
user to those with both job experience and baccalaureate 
degrees in the computer field. 

2 . Design Issues 

Although knowing the audience you are addressing is of 
paramount importance, it is also vital to know how much 
technical information to include, which information to 
include, and how to organize that information in a meaningful, 
orderly fashion. The most frequent complaints about computer 
manuals are: 

• Poorly written manuals. Computer manuals are often 
written by technicians who have no concept of how to 
present information to users without using technical 
jargon. The end product is a manual that is inadequate 
and difficult to understand. 

• Important information is hard to find. Computer guides 
that are not organized around user tasks are often 
confusing. Users have to expend extra time and effort 
deciphering the layout scheme. 

Considering the audience and issues involved, application 
documentation developed for NPS users should be brief, task 
oriented, and written in common English. Two examples of 
essential user documentation for application software, 
specifically WordPerfect 5.1 and dBase IV version 1.1, are 
included as Appendix B and C. 

E. LITERATURE REVIEW AND METHODOLOGY 

Much has been written to help professionals who write 
computer documentation to produce better manuals; however, few 
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address the development of user documentation. These 
professionals perform a variety of roles in software 
development settings, such as system designers, system 
operators, and maintenance personnel, and write different 
kinds of software documentation, such as design documentation, 
maintenance documentation, and user documentation. User 
documentation is the least standardized, supported, and 
understood of the types of software documentation noted. 
Automated systems such as CASE tools, rapidly becoming 
available for producing development and maintenance 
documentation, have not been developed for user documentation. 
Development and maintenance documentation writers generally 
follow we 11 -developed standards for the sequencing, 
formatting, and content of manuals; not so for user manuals. 
[Brockmann, 1990] 

User documentation is the most difficult for computer 
professionals to write because it requires communication with 
people who have widely different backgrounds. It dictates a 
type of writing that translates computer operations into 
English that users will understand. [Brockmann, 1990] Program 
users need documentation as a tool to help them successfully 
run and understand a program. They want documentation that 
gives them the instructions, guidance, and reference 
information they need. [Spear, 1984] 

The template approach developed by Dorothy Walsh in 1969, 
in which the writers merely fill in set templates with 
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information peculiar to their own system, initially appeared 
to solve problems of content adequacy and organization. 
However, it did not have the necessary flexibility of content 
and organization required to cope with the variability in 
audiences and purposes. [Brockmann, 1984] Replication of the 
best procedures used by the best documentation writers, rather 
than simple replication of document content, offers a method 
to prepare comprehensive and accurate documentation which 
addresses and answers the needs of targeted audiences. Using 
such a structured methodological approach not only aids the 
developer in organizing the documentation, but is also the 
primary determinant to producing a well-developed and useful 
guide . 

The procedures used to develop the user documentation for 
applications programs installed in the AS/IS computer 
laboratories are based on the Standard Documentation Process 
(SDP) described by R. John Brockmann. The nine (9) steps 
involved in the SDP include: 

1. Develop document specifications. 

2. Prototype the specification. 

3 . Draft the document . 

4 . Edit the document . 

5 . Review the document . 

6. Field test the document. 

7. Produce and distribute the document. 

8. Review the documentation project. 
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9. Maintain the document. 



F. DEFINITIONS AND ABBREVIATIONS 

Some of the concepts presented here require working 
definitions specific to this study. Also, abbreviations and 
acronyms used in the paper are defined here for the 
convenience of the reader. 

AS/IS - Administrative Sciences/Information Systems 

DDP - Documentation Development Process (Williams and Beason) 

SDP - Standard Documentation Process (Brockmann) 

Software Documentation - Unless otherwise specified, refers 
to USER documentation rather than design, maintenance, or 
other types of software documentation. 

G. ORGANIZATION OF THIS STUDY 

The first chapter is the introductory chapter, including 
sections which present a general description of the problem, 
background of the problem, objectives of the research, the 
research question, the scope, and the assumptions of the 
research project, a brief description of the research 
methodology, a list of definitions and abbreviations, and a 
description of the organization of the study. An overview and 
a review of research materials and literature relating to the 
purposes, types, problems, and causes of problems of software 
documentation, rhetorical orientation of writers, and survey 
findings on paper documentation is included in chapter two. 
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Chapter three describes the methods used for executing the 
research design, comparing documentation development 
processes, comparing screen and print designs for 
documentation, and discussing design issues and audience 
analysis. The fourth chapter discusses the test plan and 
results and the fifth chapter draws this report together with 
conclusions and some practical recommendations for developing 
and maintaining software user documentation, as contained in 
Appendixes B and C. Appendix A is a matrix of software 
programs installed on the server computers of the networks in 
the AS/IS Computer Laboratories. Appendix B is a basic users' 
guide for WordPerfect 5.1 and Appendix C is a basic users' 
guide for dBase IV 1.1. 
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II. LITERATURE REVIEW OF USER DOCUMENTATION DEVELOPMENT 



A. OVERVIEW OF SOFTWARE DOCUMENTATION FOR USERS 

The field of computer documentation is moving and changing 
quite rapidly as some of the finest minds in the professions 
and in academia turn to it as a field of study and research. 
The industry already has moved beyond merely paper manuals. 
It is in moving beyond paper that today' s writers of paper 
user manuals will be able to enter the next century with 
manual-less software in common use. Manual-less software was 
the objective of the Apple Computer's Macintosh project. 
Although they didn't fully succeed in being manual-less, the 
direction in the software industry is to take much of the 
paper documentation and make it either superfluous because of 
improved interface design, or put it online using such new 
organizational devices as hypertext. Manual-less software 
will become possible as contemporary culture increases its 
"intuitive" knowledge and sophistication concerning computers, 
and as the software itself better communicates its purposes 
and controls to the user. Even now, user documentation 
writers are not just paper manual writers; rather they are 
communication specialists who have the necessary expertise to 
design the communication elements of the "user interface" 
elements of the software: the messages, the menus, the online 
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tutorials, as well as the traditional paper manuals. 
[Brockmann, 1990] 

However, experience has shown that online documentation 
will not work unless it can be provided within the application 
program at the point in the user' s operation where help is 
needed. The methods and techniques of communication on paper 
will not be lost in the transition to a new medium, but rather 
become more important. In many cases, the qualities of 
effective online documentation must be abstracted from the 
qualities of effective paper documentation. For example, the 
concept that effective online information must allow for 
multiple access methods of getting to information can be 
easily abstracted from a book's multiple access methods that 
range from the "keyword searches" of an index, to a "top-down 
hierarchical approach" of a table of contents, to a page's 
headings that allow access to information on a local level. 
The idea of "aliasing" in keywords or online "links" is 
nothing more than the application of the concept of using 
"See" and "See also" in paper book indexes. The principle of 
effective online documentation is that we have to move away 
from effective paper documentation, abstract from paper its 
tricks and techniques, and then reinvent their tricks and 
techniques in online documentation using different tools. 
[Brockmann, 1990] 

Several documentation theories will be outlined in this 
thesis. Often, the best solution to user documentation 
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problems is an eclectic solution: a little from one writing 
style, a little from a hypertext-linking philosophy, and so 
on. Only one methodological guide remains constant and 
unyielding across all theories: the audience is always right. 
Thus, as many sides to solutions (and their defects) as 
possible are presented. [Brockmann, 1990] 

More and more documenters are breaking out of the software 
design organizations in which they merely massage written 
software design specifications. Now, documenters are getting 
information from such people as the design team of which they 
are a member right from the beginning, from actual users in 
their own environments through the application of 
documentation specification reviews and early prototype 
testing, and from fellow documenters in documentation teams 
and in structured documentation project reviews. Getting more 
information from people than from books means that 
negotiating, listening, and getting along with fellow 
documentation team members, software designers, and users will 
play much more of a role than ever in the past. [Brockmann, 
1990] "Gone are the days when writing was done after a 
product was complete and writers were given the product 
specification and told to 'pubs it up!' Today's information 
developers must work as equal partners with other product 
developers. The lines between hardware, software, and 
information are getting blurred with the advent of interactive 
programming, new input devices, and displayable manuals. For 
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this reason cooperation and collaboration across disciplines 
will become even more important and people should start 
practicing it now." [Grice, 1988] 

Computer documentation can be defined as communication 
designed to ease interactions between computer software and 
the individuals who operate it. Thus, to write software 
documentation, you must act as intermediary between the 
computer software and its users. [Brockmann, 1990] 
Inadequate user 
documentation can greatly 
increase human errors in 
computer systems. Robert W. 

Bailey categorized the major 
factors for human errors in 
computer systems . Three 

categories --environmental 
problems, personnel problems, 
and organizational accuracy 
factors-- accounted for 50% of all human errors and are beyond 
the control of the software or computer designers and 
document er s . The other 50% are within the control of the 
designers/documenters, and, of these, 60% are directly 
affected by the quality of the documentation efforts. 
Training, written instructions, and the human-computer 
interface are all affected by the quality of the 
documentation. [Bailey, 1983] 




Figure 1 Percentage of human 
errors directly affected by the 
documentation . 
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During the early years of 
computers in the 1950s, the 
standard approach to making 
computer systems 
understandable was the users' 
own trial and error. Early 
users would have to try one 
procedure after another, 
realizing what was the right 
approach and what was the 
wrong one by seeing how many vacuum tubes were blown because 
of different actions. Intelligibility was instilled in 
computer systems later by phone call support, training, and 
effective documentation. The future of computers is 

represented by "defensive programming, " which means 
anticipating problems and coding to avoid errors before they 
arise. It includes such techniques as windows-icons-mouses- 
and-pointers (WIMP). [Brockmann, 1990] 

B. RHETORICAL ORIENTATION IN THE WRITING PROCESS 

Communication takes place in a context called the 
rhetorical situation, which includes an encoder (writer) and 
a decoder (reader or user) , each having a purpose for reading 
or writing. Communication is effective when the message 
received by the decoder is nearly the same as the message sent 




instilling system 
intelligibility . 



15 



by the encoder. [Pesante, 1991] Rhetorical orientation 
includes such factors as [Sullivan and Porter, 1990] : 

• the writer's model of communication- -that is, the writer's 
beliefs about the way discourse works, the way it ought to 
be produced, and the way users ought to respond to it. 

• the writer' s beliefs about priorities in writing--what are 
important criteria and how do we measure writing 
ef fe ctiveness? 

• the writer' s attitudes toward authority--where will we 
look for answers? what authorities should we call upon? 

• the writer's conviction to a specific document--to what 
degree is the writer an advocate for the document? for the 
system? for the user? 

"Noise" that prevents effective communication includes 
ambiguity, mistaken assumptions, emotional reactions to a 
topic or word choice, insensitivity of the writer to the needs 
of the reader/user, overuse of passive voice, long, convoluted 
sentences, and so on. To be effective, a writer must analyze 
all the elements of the rhetorical situation and the 
relationships among them: reader/user (s) , writer (s), subject 
matter, and language. It is especially easy in technical 
writing to concentrate on the subject matter and neglect the 
other elements. [Pesante, 1991] 

Studies have shown that a writer' s use of information is 
guided by that writer's rhetorical orientation, particularly 
his/her view of the audience/user. [Sullivan and Porter, 
1990] From the perspective of theories of writing and 
rhetoric, user-centeredness has a solid basis in historical 
precedent . Rhetoricians have always been concerned with the 
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importance of occasion in 
defining the purposes or aims 
of a piece of communication. 

Placing the audience at the 
center of discourse 
production has also been a 
significant feature of 
rhetoric and writing study, 
so user analysis is a logical 
extension of this research. 

Modern composition theorists have drawn upon the traditional 
communication triangle of encoder/decoder/reality to give a 
conceptual image to the writer/reader/subject triangle. The 
rhetorical framework of user-centered documentation is 
reconstructed in Figure 3, to give a clear, conceptual view of 
the parameters of the discursive territory in question. 
[Johnson, 1990] 

C. SOFTWARE USER DOCUMENTATION PURPOSES 

Some of the specific purposes of user documentation are to 
improve efficiency, to overcome users' fears of equipment or 
software, and to sell the product. 

People need to understand the systems with which they are 
working. During usability testing of a desktop publishing 
tutorial, the documentation writer discovered that persistent 
problems users had with the tutorial were tied to conceptual 
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Figure 3. The Communication 

Triangle of a User- 
Centered Rhetoric 
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issues. His verbal explanations to the users of how the 
software program works and how it differs from word 
processing, as well as his description of the systematic 
operation of the computer system on which the users were 
working, generated interest in the users and resolved some of 
their problems. [Sullivan and Porter, 1990] 

When users of new software confront a complicated and 
poorly-organized set of reference manuals as their 
introduction to a piece of software, they are apt to regret 
their introduction. On the other hand, if they see a 
simplified tutorial for the same software, they are more 
likely to forge ahead. [Brockmann, 1990] The tutorial on 
desktop publishing mentioned previously was developed as a 
lock-step, directional guide which maintained a consistent 
tone, style, and design throughout. Users praised the 
simplicity and directive approach, particularly early on when 
they were least confident. Eighty percent of the users 
reported feeling good about what they had learned about the 
software program, indicating that they felt confident enough 
to try the program on their own in the future. [Sullivan and 
Porter, 1990] Successful software documentation, then, leads 
to successful first encounters with software and hence to 
greater acceptance and use. [Brockmann, 1990] 

Most people agree that the quality of documentation for 
the end-user can make the difference between success and 
failure for a new software product. The manuals are what the 
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customer sees first and therefore they shape the perception of 
the entire package. [Brockmann, 1990] Also, research 
indicates that documentation is the most important potential 
point of difference between software producers. When software 
products are perceived as fairly difficult to use, 
documentation can change customers' minds or not. "User 
friendly documentation shows off user friendly software; 
together, they win customers and customer loyalty." [Borland, 
1984] 

D. TYPES OF SOFTWARE USER DOCUMENTATION 

User documentation can be classified in two ways: First, 
it can be classified by content --reference material and 
tutorial material-- and second, by environment --external 
documentation and internal documentation. Knowing the 
different types of documentation will help to make decisions 
on what to include in a documentation package in response to 
the audience and the software. [Brockmann, 1990] 

Reference material is technical, detailed, comprehensive, 
and usually organized like an encyclopedia or dictionary for 
quick retrieval of information. A reference manual should 
explain what the software can do for the user rather than 
comprehensively describing the product. An emphasis on 
product capability in a reference manual allows the user to go 
beyond the necessarily constrained steps of a tutorial, and 
combine product features in creative ways. The emphasis of 
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the former is on product capability as opposed to an emphasis 
on product internal construction, as with the latter. 
[Brockmann, 1990] 

Tutorial material selects from the comprehensive reference 
material and presents information in a step-by-step fashion. 
It is usually organized around user tasks or a hierarchy of 
user needs. [Brockmann, 1990] 

A 15-year survey of users carried out by Control Data 
Corporation, Scientific Data Systems, and Xerox Data Systems 
resulted in two apparently contradictory findings. Half the 
users thought manuals had too little detail, and half thought 
they had too much detail. Two-part manuals, with a tutorial 
and a reference section, were suggested as a compromise by the 
survey takers. By clearly segmenting the manual in two parts, 
the user can choose the coverage of material appropriate for 
his/her particular situation. [Brockmann, 1990] Borland 
described much diversity in views of documentation between 
users with little computer experience and programmers with up 
to twelve years experience. Borland's "solution manual" was 
one with a tutorial, a reference, and a "cookbook" (filled 
with "recipes" to accomplish tasks and procedures for using 
illustrations, both of the steps and of the result) . 
[Borland, 1984] 

Selection of material coverage for a software manual 
should also be influenced by the "open-endedness" (how much it 
can be customized, used, and viewed in different ways) of the 
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software to the user. General database development packages, 
for example, are open-ended to a greater extent than a spell- 
checker/ thus, the material in the database manual would 
probably be presented as a reference manual. In a software 
package which can be viewed or used in only one way, such as 
the spell-checker software, the more appropriate manual 
presentation would likely be a tutorial. This is especially 
true since tutorials tend to limit the users' conceptions of 
the uses of the software because of the specificity of 
directions and examples. This may not be desirable for open- 
ended software packages. 

External documentation is meant for audiences outside the 
corporate or organizational environment in which the 
documentation is developed. It is usually a more expensive, 
professional product, being a marketing tool as well as an 
operations tool. It is usually attractively packaged and 
filled with graphics. [Brockmann, 1990] 

Internal documentation is developed by an organization to 
be used by people within that same organization. It makes up 
the bulk of all documentation, yet it frequently fails to 
receive the necessary time, money, and attention because it is 
used only inside an organization and is not part of a product 
to be marketed. Thus, it is not directly related to profit 
making. Also, internal documentation is not as well designed 
as external documentation because the writers usually do not 
seek or receive as much feedback. [Brockmann, 1990] However, 
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an internal manual that is targeted to a specific audience 
could be superior to a generalized external manual with 
respect to relevance, simplicity, and brevity. 



E. PROBLEMS WITH SOFTWARE USER DOCUMENTATION 

There can be many problems with documentation that render 
it inadequate or ineffective. Some examples of problems are 
[Brockmann, 1990]: 

• Layout and Style Problems: misprints, use of ordinary 

prose, overuse or underuse of paragraph numbering, lack of 
or poor highlighting scheme, style that is not conducive 
to skimming and scanning 

• Organizational Problems: not organized to aid the 

reader's search for information, no preface telling the 
who, what, and when behind the document, announced order 
of presentation of material not followed, order of 
material not intuitive, not apparent, or not supported by 
graphics, often-used commands not clearly separated, 
summary of procedures not clearly set out at the beginning 

• Audience Analysis Problems: important information missing 

or unimportant information cluttering explanations, lack 
of graphics, figures, and other supporting information 

• Consistency Problems: programs, commands, functions not 

having same name throughout, formats and layouts changing, 
phraseology and wording not staying the same as much as 
possible, numbering for sections and subsections not 
consistent, transitions from topic to topic or screen to 
screen not obvious 

• Poor Reference Aid Problems: lack of or incorrect table 

of contents or indexes, not enough level of detail in 
table of contents, illustrations, figures, and tables not 
numbered, titled, or listed 

• Update Problems: no plan for updating, handwritten notes 

used to update 

• Language Problems: words such as files and records used 

without explanation, no glossary, inappropriate words 
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used, words used interchangeably which do not mean the 
same thing, unclear or conflicting instructions 

F. CAUSES OF INADEQUATE SOFTWARE USER DOCUMENTATION 

Seven factors contribute to the problems causing the 
production of poor user documentation. 

• The change from centralization to decentralization of 
computer systems 

• Institutional limitations 

• Inadequate design documentation 

• The techniques used in user documentation 

• Oversimplifying the writing task in many how-to books and 
professional journals 

• Fighting against rather than harnessing the learning 
behaviors adults spontaneously adopt 

• Natural egoism 

Many writers have had difficulty adjusting to the change 
in the place and function of user documentation. In the 1950s 
through the early 1980s, computer systems were mostly 
centralized and surrounded by software specialists who could 
translate any user documentation that users did not 
understand. With the shift toward decentralization, where 
microcomputers and workstations stand alone throughout 
organizations and geographic locales, software specialists are 
not available to translate or train at each node. Thus, user 
documentation must also be able to stand alone. Too many 
writers continue writing in the centralized frame of mind. 
[Brockmann, 1990] 
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Even when documenters are alert to the needs of 



documentation in a decentralized environment, institutional 
factors may still prevent them from producing effective 
computer documentation. First, training and education are 
lacking in many organizations. Second, company standards 
which support and enhance good, effective documentation often 
do not exist. Similarly, if examples of documentation 
formally presented in standard development methodologies or 
informally circulated in an office are not examples of good 
documentation, training and official company standards may go 
for naught. Finally, good, effective technological support of 
the documentation effort enhances the likelihood of good 
documentation. The various iterations of a document should be 
completed as faultlessly and as quickly as possible. Speed of 
production is crucial because good documentation is the result 
of continuous rewriting. The longer and more laborious the 
process, the less inclined documenters will be to redraft and 
rewrite. Hence, the more powerful the tools that are put in 
the hands of the documentation developers, the better the 
final document will be. Underlying these institutional 
factors are management support and encouragement. Good or bad 
documentation and the climate producing either are largely a 
function of management. [Brockmann, 1990] 

To write an effective piece of computer documentation, a 
writer needs full and complete information on the design of 
the system or the program. Without a solid foundation of 
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complete, clear, and accurately-written design documentation, 
user documentation writers must expend more time and effort in 
interviews with designers, making educated guesses, and 
repeatedly reviewing and rewriting. [Brockmann, 1990] 

The techniques required for writing user documentation 
differ radically from those required by essays or the like. 
The basic difference is that between arranging information for 
sequential access and arranging it for random access. 
Computer documentation must be able to be easily scanned and 
skimmed. [Brockmann, 1990] 

Oversimplification occurs when documentation writers turn 
for help to commercially published instructional texts which 
do not adequately alert them to the effects that audience 
variations have on documentation projects and products. As an 
example, the use of templates, in which writers needed only to 
fill in set templates with information peculiar to their own 
system, initially appeared to solve problems of content 
adequacy and of organization. As template use developed, 
however, it essentially confused sophisticated data processing 
users who had extensive prior knowledge with users who had no 
such knowledge and needed much more. [Brockmann, 1984] 
Today, new problems may be caused with the advent of industry- 
wide, corporate-endorsed, research-based guidelines and user 
interface standards. These standards may cause problems in 
four ways [Brockmann, 1990] : 
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• First, to be generally applicable, they often fail to be 
sufficiently specific to the users' tasks 

• Second, they can foster a superficial consistency 

• Third, research data are currently too incomplete to 
support all the rules in these standards and so "best 
guesses" are packaged indistinguishably with "soundly 
researched principles" 

• Fourth, and most important, guidelines, rules, and 
standards invite documenters to forgo testing with real 
users . 

Some adults resist explicitly addressing themselves to new 
learning. Two paradoxes, motivation and assimilation, are 
described as explanation for this kind of behavior. The 
motivation paradox is the "production bias" people bring to 
the task of learning and using computers. The chief goal is 
throughput, reducing motivation to spend any time just 
learning about the system; so, when situations occur that 
could be more effectively handled by new procedures, people 
are likely to stick with those they already know regardless of 
their efficacy. The assimilation paradox is that people apply 
what they already know to interpret new situations. Though 
often helpful, irrelevant and misleading similarities between 
the new and old information can blind learners to what they 
are actually seeing and doing, leading them to draw erroneous 
conclusions or preventing them from recognizing possibilities 
for new functions. [Carroll and Rosson, 1987] In the design 
of documentation that takes the "systems" approach, which 
focuses on step-by-step procedures in which the reader is 
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expected to be passive and just follow along, these two 
paradoxes can become problematic. [Brockmann, 1990] 

Natural egoism is the final factor that can adversely 
affect documentation. A writer will not be effective until 
he/she is able to empathize with the readers and recognize 
that the readers approach software documentation with 
different backgrounds, expectations, training, and education. 
[Brockmann, 1990] 

G. SURVEY FINDINGS REGARDING PAPER DOCUMENTATION 



Table 1 summarizes the common recurring findings of the 
four marketing surveys described in this section. 



Major Consistent 
Findings for 
Paper 

Documentation 


Xerox, 

Control 

Data, 

Scientific 

(Maynard, 


AT&T 

(1986) 


Microsoft 

(Borland, 

1984) 


PC-User 

Group 

(Wilton, 

1985) 












More task- 
orientation 


X 


X 


X 




More tutorials 




X 


X 


X 


Improved 
reference aids 


X 


X 


X 


X 


More accuracy 




X 




X 


More 

illustrations 




X 


X 


X 



Table 1. Recurring findings in user surveys of paper 
documentation 

The 15-year survey of users carried out by Xerox, Control 
Data, and Scientific Data Systems [Maynard, 1982] and a 
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parallel survey carried out with military users [Beard and 
Callamars, 1983] showed the major complaints to be: 

• Manuals were software-oriented rather than function- 
oriented 

• Manuals did not have enough examples 

• Manuals did not have enough reference aids 

An independent market research firm conducted an external 
documentation market survey for AT&T in 1986. The survey 
identified features of documentation that both users and 
dealers thought were important factors in selecting one 
software package over another. Major themes were that 
information in AT&T manuals should be: 

• Easy to find: better reference aids were recommended 

• Easy to understand: not assume too much, have graphics, 
and be task oriented 

• Complete, accurate, and current 

• Indexed: absence of an index was a definite reason to 

avoid purchasing a software product 

Microsoft Corporation conducted a documentation survey in 
1984 [Borland, 1984] which found that end users wanted: 

• task-oriented tutorials. 

• screen illustrations and terms explained in glossaries. 

• reference cards which listed first all the commands and 
then the tasks with commands used to complete them. 

• a feature-oriented/command index as well as a task- 
oriented index. 

• a task-oriented organization. 

• a reference manual that comprehensively described all the 
features of the product. 
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• trouble-shooting guides. 

A PC User Group conducted a survey of 241 microcomputer 
owners [Wilton, 1985] . Table 2 portrays the contrast between 
what readers said they wanted and what was actually delivered. 



Do you agree or disagree? 


Agree 


Dis- 

agree 


Manuals should accommodate all users 


86 


7 


vs . 






Manuals do accommodate all users 


16 


58 


Tutorials are usually helpful 


66 


12 


vs . 






Many manuals omit tutorials 


65 


8 


Illustrations should substitute more 
for text 


70 


15 


vs . 






Illustrations are adequate in number 


18 


54 


Information is easy to find 


11 


67 


vs . 






Manuals bury important information 


89 


4 



Table 2. Contrast between what users want and what users 
get . 
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Ill, FUNCTIONAL ANALYSIS AND DESIGN 



A. COMPARISON OF USER DOCUMENTATION DEVELOPMENT PROCESSES 

The software user documentation development process is 
defined and executed differently, depending on where you are 
and who you talk to. There seem to be as many processes as 
there are organizations who develop software or authors who 
write about developing software. Three treatments of software 
user documentation development processes are presented by 
Brockmann [1990], Weiss [1985], and Williams and Beason 
[1991] . 

Brockmann [1990] revised his original seven-step Standard 



Documentation Process 


(SDP) which 


came out in 


1986 to 


accommodate the 


many 


deve 1 opmen t s 


in the area 


of 


user 


documentation . 


His 


nine-step SDP 


version 2.0 


now 


gives 



information on CASE tools, new programming technologies, 
research on layout, format, typography, and use of color, 
desktop and electronic publishing, new documentation 
databases, and the effects of new techniques, technologies, 
and ideas, such as team writing styles, document prototyping, 
minimalist design philosophy, hypertext, and mass storage 
devices like CD-ROM and magneto-optical storage. The SDP 
replicates many tried and tested procedures used by well- 
respected, successful documentation writers. Figure 4 and the 
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following list give an overview of what is involved in the 
SDP . [Brockmann, 1990] 




[Brockmann, 1990] 

• Step 1. Develop Documentation Specifications. In this 
first step, planning the documentation occurs in two 
passes. The first pass is the development of a Library 
Specification that contains a brief description of all the 
documents involved with a particular software program or 
system. This plan gives an opportunity to communicate the 
"big picture" of the whole writing project to management 
or clients. The second pass is the development of the 
Individual Document Specification. This second blueprint 
follows the Library Specification and communicates the 
specific plans for a single document to management, 
clients, and users. Eleven activities are involved in the 
creation of these blueprints: breaking down the 

documentation in the library by tasks, using minimalist 
design principles, planning for an audience, analyzing the 
purpose of the documentation, organizing the material, 
developing a product visualization, picking the 
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appropriate media, deciding on page format and layout, 
planning for updating, considering the competition, and 
estimating cost and time requirements. 

• Step 2. Prototype the Specification. Since the ultimate 

test for paper or online documentation is usability, 
document designers should iteratively test their pages and 
screens with users. Prototyping is repeatedly done with 
a document as it is being developed, but it basically has 
four steps: prepare for the test, instruct the testers, 

run the test, and analyze and apply the results. The 
results of prototyping should give guidelines for depth of 
coverage, vocabulary, readability, and organization. 

• Step 3. Draft the Document. Once the specifications have 
been created, approved, and tested, it is time to draft 
the document. Seven activities make up this step: 
overcoming internal and external writing blocks, using a 
writing style that is designed to match adult reading 
behaviors, using reader-based writing techniques, 
developing effective graphics, creating reference aids, 
developing the documentation packaging, and planning for 
updates . 

• Step 4. Edit the Document. Now that the document is 

drafted, it is revised so that it effectively and 
efficiently gets its message across. This is primarily 
accomplished by using levels-of-edit techniques. 

• Step 5. Review the Document. Once the document is 

drafted and edited, it is sent out for review. To have an 
effective review, carefully choose reviewers and the time 
to review, show reviewers how to review, and give them 
feedback. 

• Step 6. Field Test the Document. A part of every 

document's review should be a field test of a draft of the 
whole document. Where prototyping examined the pieces of 
a manual or online document during their creation and 
assembly, field testing examines how the document works as 
a whole. Accessibility, navigational problems, and 
consistency are primary areas of concern here. In 
conducting a field test, carefully choose field testers 
and the time to field test, run both an in-house 
"controlled" field test and an external field test, and 
provide feedback to field testers. 

• Step 7. Produce and Distribute the Document. Once the 
document is drafted, revised, and reviewed, it is produced 
in a form suitable for distribution. With paper and 
online publishing mechanisms ranging so widely, and 
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multimedia publishing becoming more and more prevalent, 
preparing text via an SGML-like tagging system becomes 
essential . 

• Step 8. Review the Documentation Project. Once a 
document is complete, and before beginning a new project, 
analyze what went right and what went wrong during the 
process of developing the documentation so that 
improvements to the process can be implemented during the 
next project, and mistakes and problems thereby 
alleviated. 

• Step 9. Maintain the Document. Even when the document is 
distributed, the task is still not completed because the 
document must be updated. To do this effectively, 
responsibility for updating a document should be clearly 
assigned. Distribution of the document should be tracked 
so that one knows where to send updates and the changes in 
the updates should be clearly indicated. 

Weiss [1985] describes five phases of user documentation 
in his Structured Process, all of which he believes necessary 
for effective, usable documentation. By structured, he refers 
to a formal, top-down decomposition of the user documentation 
development process into a development model which is designed 
so the components of the process are interconnected in the 
"best possible way." [Weiss, 1985] Figure 5 is a data flow 
diagram of the five phases, showing the development flow for 
user documentation. A brief description of the five phases of 
the Structured Process follows. 

• Phase 1. Analysis. Define just what manuals and other 
information products the users and operators need. The 
earlier in the life of the system the analysis takes 
place, the better. Ideally, the documentation analysis, 
which often culminates in a Publications Plan in large 
projects, should occur as part of the original system 
development plan, but it is never too late to analyze the 
remaining documentation need. 

• Phase 2. Design. Prepare detailed outlines of each 
manual or other information product. This phase starts 
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Figure 5. Data Flow Diagram for 
Developing User Documentation using 
A Structured Process. [Weiss, 1985] 



• with the preparing of conventional outlines, but then 
proceeds to the creation of "structured outlines" and 
"storyboards" -- working models of the documents that can 
be tested and revised before the first draft is written. 
The most difficult structural and organizational problems 
must be corrected before the first draft is written. 

• Phase 3. Assembly. Convert the storyboard to a work plan 

and write the first draft. In the structured approach to 
documentation, writing the first draft is a little like 
writing the code in a structured program: that is, the 

writers do little more than fill in missing details, 
according to a strictly-followed plan, the "storyboard." 



• Phase 4. Editing. Test the first draft for clarity, 
correctness, and readability. In this approach, questions 
of language and style are more than matters of esthetics; 
rather, the purpose of this phase is to apply principles 
of editing that make the manual easier to use, and 
therefore less likely to cause a "failure" (defined as 
what occurs when an operator or reader us unable to work 
the system because of a bug in the manual) . In many 
cases, this phase culminates in a test with "live" 
readers . 

• Phase 5. Maintenance. Track what needs to be changed in 
the information products and, when appropriate, make the 
changes. Because all manuals are flawed or out-of-date 
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(without exception, according to Weiss) , the last phase of 
documentation is to monitor what should be added, removed, 
replaced, or repaired. The craft of maintaining user 
documents is knowing what changes must be made and being 
able to distribute and incorporate those changes in a 
manner that does not generate confusion and additional 
errors . 

Williams and Beason [1991] view software development 
projects as having nine phases. These nine phases somewhat 



Table 3. User Documentation in the Software Development 
Process. [Williams and Beason, 1991] 



Phase 


User Documentation 


1 Feasibility 
Analysis 




2 Requirements 
Definition 




3 Alternatives 
Analysis 




4 Functional 
Specifications 




5 Preliminary 
Design 


Documentation plan 


6 Detailed Design 
and Construction 


Outline (s) for user documentation 
First draft (s) of users' manual (s) 
First draft (s) of online help system 


7 Verification 
(alpha and beta 

tests) 


Reviews of first drafts 

Usability tests of tutorials and procedures 
guides 

Review, linking, and testing of online systems 
Final draft (s) of users' manual (s) 

First and final drafts of quicX reference pieces 


8 Implement at ion 


User documentation completed 


9 Maintenance 


Revisions and addenda 



correlate with the seven phases of the Standard Software 
Development process from the IEEE Software Engineering 



35 



Standards reference [1990] : Concept, Requirements, Design, 

Implementation, Testing, Installation and Checkout, and 
Operation and Maintenance. According to Williams and Reason, 
the user documentation development process begins during phase 
five of a software development project and continues 
throughout the remainder of the life cycle of the project. 
Table 3 shows how Williams and Beason [1991] believe user 
documentation fits into the overall software development 
process. As you can see, their Documentation Development 
Process generally comprises five phases, as follows: 

• Phase I. Documentation Planning. Locate and review 
existing information and confer with team members. Decide 
how many and what types of individual documents (manuals 
or other printed pieces) and online materials are needed. 
Decide on the goals of the documents. Write a profile of 
the audience. Determine production methods, including the 
means for creating illustrations, producing a final draft, 
and reproducing or printing the required number of copies. 
Describe the physical appearance of the document, put the 
plan on paper, and get it approved. Draft a schedule and 
get it approved. Create a style guide. 

• Phase II. Outlining and First Drafts. Review information 
in the documentation plan about readers and their needs, 
and the goals of the document. Decide how to organize the 
document. Draft a preliminary or working outline of the 
printed documents, including quick reference materials. 
Draft a preliminary outline of the online materials. 
Review the outlines and revise them if necessary. Get the 
outlines approved. Write the first draft. Write or 
review the first draft of the online materials. Make a 
preliminary list of illustrations. Read and revise the 
first draft. Update the list of illustrations. Send the 
draft out for review. 

• Phase III. Subsequent Drafts, Usability Testing, Final 
Drafts. Incorporate comments and corrections from the 
review. Do any necessary rewriting. Make copies of 
completed illustrations and insert them in the draft. 
Proofread and correct the draft, covering both text and 
illustrations. Send the draft out for review. Review and 
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correct online materials. Conduct usability tests of 
tutorials and procedures guides. Review, link and test 
online systems. Incorporate comments and corrections from 
the prior review of drafts. Read all text and review 
illustrations, checking for flow, clarity, and 
completeness. Write quick reference materials. Get final 
okays on changes from reviewers. Have quick reference 
materials reviewed and proofread. Check text and 
illustrations for consistency, and proofread for 
typographical, spelling, or placement errors. Indicate 
spaces for illustrations. If necessary, mark headings, 
words, or phrases that need special emphasis, and page 
breaks. Review online materials for the final time. 
Correct quick reference materials. 

• Phase IV. Production. Produce the text by typewriter, 
word processing software, or computerized typesetting. 
Proofread the text. Make up pages, merging text and 
graphics. Check for continuity and positioning of 
illustrations. Number the pages of the document if 
needed. Prepare the table of contents and index. 
Proofread page numbers for the index and table of 
contents. If the document is being professionally 
printed, check the blue line (sample of printed document) 
for accuracy, consistency, and placement of text on pages. 
Print or duplicate the required number of copies. 
Assemble, bind, and distribute documents. 

• Phase V. Maintenance. Prepare, incorporate, and 
distribute revisions and addenda on an ongoing basis as 
necessary . 

Although the number and definitions of the phases and 
steps in each of these processes vary, all have commonalities 
which must be viewed as mandatory in any software user 
documentation development process. A comparison of the three 
approaches to the documentation process is provided in Table 
4 . However the steps or phases are organized, the actual 
processes all contain the elements of planning, designing, 
drafting, rewriting, testing, producing, distributing, cind 
maintaining the software user documentation developed. 
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Table 4. Comparison of Software User Documentation 
Development Processes. 



SDP [BrocJonann, 1990] 


Structured Process 
[Weiss, 1985] 


Document Development 
Process [Williams £ Besson, 
1991] 


1 . Doc Specs 


I. 


Analysis 


I . Documentation 


2 . Prototype 


II. 


Design 


plan 


3 . Draft Doc 


Ill 


. Assembly 


II. Outline £ First Draft (s) 


4. Edit 


IV. 


Editing 


III. Reviews, Tests, Final 


5 . Review 






Drafts 


6. Field test 








7 . Produce/Dietro 






IV. Production 


8. Review Project 


V. Maintenance 


V. Maintenance 


9 . Maintain 









Since the development methods studied displayed 
commonality, the decision on which method to use for 
development of the user's guides for the AS/IS Computer Labs 
at NPS was based on versatility, applicability, complexity, 
completeness, and currency of the method. This researcher was 
looking for a method which has the following attributes: 1) 
versatile enough that it could apply across most development 
situations; 2) easy to understand; 3) speedy assimilation; 4) 
sufficiently complete; and 5) applicable to military graduate 
students. Also, this researcher desired a method which had 
been developed or updated within the last couple of years so 
that its techniques would incorporate industry advancements 
and evolutions. For these reasons, a combination of the SDP 
formulated by R. John Brockmann [1990] and the Documentation 
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Development Process formulated by Williams and Beason [1991] 
were selected as the guides for creating the user' s guides 
contained in the appendixes of this paper. 



B. COMPARISON OF SCREEN AND CATEGORIES OF PRINT DESIGN 

The content-classified types of software documentation 
(reference and tutorial) discussed in Chapter 2 can be further 
categorized into five basic classifications [Williams and 
Beason, 1991] : 

• Tutorial: Teaches basic program functions through 

controlled "lock-step" practice sessions 

• Procedures guide: Explains and gives step-by-step 

instructions about how to perform all the functions of the 
program 

• Reference material: Describes in detail commands, 

functions, fields, key assignments, and/or messages 

• Quick reference piece: Lists the most frequently used 

commands, functions, or key assignments (may be a card, 
keyboard template, small guide booklet, or single-page 
document) 

• Online help system: Displays information on the screen 

while the program is running 

The following chart aids selection decisions with regard 
to the categories of documentation to produce [Williams and 
Beason, 1991] : 
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TYPES 



Tutorial 



Procedures guide 



Reference 

material 



Quick reference 
piece 



Online help 
system 



USE WHEN 

Users are novices 

Users must teach 
themselves 

Users need to get 
started quickly 



Program is 
complex or 
interface is 
int imidating 

Users have some 
experience or 
program is simple 



Users know how to 
use features and 
are familiar with 
the interface 



Users are 
experienced with 
the program 



Users need 
information while 
running the 
program 



ADVANTAGES 

Builds confidence 

Lets users 
practice 

Allows quick, 
user-friendly use 
of program 
features 



Allows users to 
choose only 

procedures they 
need 

Information is 
complete, 
arranged in task- 
oriented 
groupings 

Allows quick 

access to details 



Allows users to 
approach 
information from 
many angles 

Quickly reminds 
users which 
commands , 
functions, or 
keys to use 

Allows users to 
get assistance 
without looking 
away from the 
screen 
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The decision about which categories of documentation to 
produce depends on the needs of the audience and on the budget 
and schedule. For documenting only an application, a 
procedures guide may be sufficient; for documenting a 
programming language, a reference manual may be adequate. 
Generally speaking, no one category of documentation can 
please all types of users. [Williams and Beason, 1991] For 
the purposes of this study, task-oriented procedures guides, 
also called a user's guides, were selected for production, 
based on the audience analysis and limited budget and 
schedule, and because effective, complete online documentation 
was already available via the online HELP features offered by 
both WordPerfect 5.1 and dBase IV 1.1. 

C. DESIGN ISSUES 

Normally, the first exposure a new user will have to a 
system is through user's manuals. Careful planning must be 
devoted to the design of documentation since inadequate design 
results in end-user dissatisfaction. Readers only use 
documentation to get their job completed when it requires some 
kind of computer assistance. Thus, the best design for 
software documentation is the one that fits the users' methods 
of working and requires the least attention and learning. 

In designing the user's guides for the AS/IS Computer 
Labs, the researcher focused on organization, content, layout, 
and language. It is thought that these elements are the four 
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factors that most impact the effectiveness of the 
documentation design. [Gleason, 1986] 

1 . Organization 

Widely used in the industry until recently, a software- 
internals orientation approach to documentation design 
concentrated on the structure and facilities of a program 
rather than on the user' s use of that program. This approach 
received extensive criticism in the 15-year survey of users 
carried by Xerox, Scientific Data, and Control Data 

corporations. Users almost always preferred task-oriented 
manuals because a software-internals orientation forces users 
to center their business duties around the software rather 
than vice versa and because users must know the structure of 
the software before being able to use the documentation. 
[Maynard, 1982] On the other hand, a task orientation is 
based on an analysis of the user's use of the program and is 
limited to what information is required to do a specific task 
using the program. Thus, the focus is turned from the system 
to the users using the system in their daily work. 
[Brockmann, 1990] "Having the user at the center ... allows for 
concentrated efforts from diverse fields toward a common goal: 
the development of usable documents for whatever medium may 
come our way." [Johnson, 1990] 

The IEEE Standard for Software User Documentation [IEEE 
Std 1063-1987, 1988] states that: 
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"Users of software need documents either to learn about 
the software (instructional mode) or to refresh their 
memory about it (reference mode) . Instructional mode 
documents may be either information- or task-oriented. 
Information-oriented documents give the reader information 
needed to understand the computer software and its 
functions; task-oriented documents show the reader how to 
complete a task or reach a goal." 

The end products of this paper, two applications user's 

guides, are more for reference than instruction, but contain 

some general information about the application software and 

its functions. The primary purpose of each was to guide 

certain NPS students on their own or, if desired, as a 

supplement to instructional courses, through the basic 

procedures of word processing (in the case of WordPerfect 5.1) 

and working with a database management system (in the case of 

dBase IV 1.1) . Thus, a task-oriented approach was adopted. 

A task orientation, in which the designer selects 
content and employs an organization appropriate to a user' s 
work needs, points to use of the minimalist design philosophy. 
The goal of a minimalist design philosophy is to present 
material appropriately to the actual ways adult learners learn 
rather than fighting against their natural tendencies the way 
a "systems" (e.g., software-internals) design philosophy does . 
[Brockmann, 1990] Research has verified that adult learners: 

• Are impatient learners and want to get started quickly on 
something productive 

• Skip around in manuals and online documents and rarely 
read them fully 

• Make mistakes but learn most often from correcting such 
mistakes 
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• Are best motivated by self-initiated exploration 

• Are discouraged, not empowered, by large manuals with each 
task decomposed into "irritating" subtask detail 

The key idea is to present the smallest possible obstacle to 

learners' efforts by providing less overt training structure. 

[Carroll, 1990] The minimalist design tips used in creating 

the user' s guides in Appendix B and C include [Brockmann, 

1990] : 

• Minimize secondary features of manuals and online 
documents (overviews, introductions, summaries, etc.). 

• Focus on what readers need to know to immediately apply it 
to productive work. 

• Make it easy for the reader of a page to coordinate the 
documentation with the screen information by grouping 
instructions and cursor movement /navigation key tables 
together by the screen to which they apply 

• Use what the readers already know by continuously linking 
new information to it 

The DDP exhorts designers to organize the guide and 
group procedures to reflect the way users will use the 
program, such as listing the procedures for entering 
information before listing the procedures for editing that 
information. Additionally, designers should include all the 
information needed to successfully complete each procedure. 
Additionally, each procedure module should be organized 
internally, so the modules will be consistent. [Williams and 
Beason, 1991] In the user's guides appended to this paper, 
for example, each procedure module contains a heading (name of 
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procedure) , brief introductory paragraph, and numbered steps 
of the procedure. 

Brockmann [1990] lists two primary principles of 
organization, both of which were followed in organizing the 
text material in the appended user's guides. 

• Make the organization of material apparent to readers. 
Essentially, that means that with words, graphics, or 
layout, "Tell the folks what you're going to tell 'em 
before you tell 'em." 

• Organize documentation in ways expected by the readers. 
Using general-to-specif ic and explanation-to-specif ic 
conditions works effectively; that is, instructions state 
a general procedure which is applied to the specific 
context. Also, readers expect information to be presented 
in chronological order, most-important-to-least-important 
order, order of need, and order of difficultly. 

The length of a user' s guide varies depending on the 
subject matter. This researcher tried to limit the 

WordPerfect guide to fifteen pages of material, which would 
adequately cover all basic functions to be performed by the 
target audience. Since a database management software program 
is generally so much more complex than a word processing 
program, the dBase IV guide required approximately thirty 
pages to adequately cover the material needed by the target 
users . 

2 . Content 



The content is the part of the manual that describes 
operations. It focuses on commonly-used tasks and its 
productivity is measured in terms of relevancy to the user. 
The key to selection of tasks to be covered was the "80-20 
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Rule." The 80-20 Rule is that the user's guide should cover 
the 20% of the tasks that are used 80% of the time. 

An overview of the project also helps define what 
information should be included. Elements that should be 
considered are [Williams and Beason, 1991] : 

• General purpose of the project 

• Intended users of the software 

• Features of the software 

• Features that are outstanding or that make it different 
from other similar software 

• Operating system and other related software 

• Computer and other related hardware 

• Network or larger system the software may be part of 
Only the content that the user needs should be included. The 
manual should be as brief as possible, but not at the 
sacrifice of pertinent information. 

3 . Layout 

A good layout can make a manual more readable and give 
the writer the means for presenting information clearly and 
cleanly. A layout for a software manual must meet two goals: 
to make it easy for users to absorb information on the first 
reading and easy for them to locate specific bits of 
information later when they may need them. Generally, to 
design a manual which meets both these requirements, the 
writer must [Williams and Beason, 1991] : 
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• Format the separate elements consistently so the readers 
can identify them at a glance. All procedures should look 
alike . 

• Use a generous amount of white space (blank space) on the 
page. Information stands out on a page with white space 
and the pages are less tiring to read. 

• Use headings to show the structure and hierarchy of the 
information. Format them so they stand out from the text 
and so the subordination is clear. 

• Make columns of text no wider than 65 to 70 characters per 
line (4-5 inches) . Wider lines of type are hard to read. 

Documents are usually made up of three major sections: 
the front matter, the main text, and the back matter. The 
front matter includes all or some of the following: title 

page, copyright or acknowledgements page, table of contents, 
list of figures and/or tables, symbols and conventions page, 
and installation and start-up guidelines. The main text is 
the introduction and main body of the document. The back 
matter contains any appendixes needed, a glossary, and an 
index. [Williams and Beason, 1991] For simple, in-house 
documents, such as those created for this study, only the 
parts considered absolutely essential are included. 

4 . Language 

If you want users to get the most out of the program, 
use language that is clear, strong, and direct. Williams and 
Beason [1991] and Brockmann [1991] provide many guidelines 
which were considered when formulating the user's guides: 

• Use nonsexist language: Use generic titles and 

descriptions (e.g., chair instead of chairman) and 
nonsexist pronouns and adjectives. Some techniques to 
help include addressing readers directly (e.g., You can... 
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instead of He can. . .) / use the plural form rather than the 
singular (e.g., programmers keep their disks. . . instead of 
a programmer keeps his disk...)/ if the title must be 
singular, substitute an article (a, an, the) for a pronoun 
(e.g., the operator enters a password rather than the 
operator enters his password) ; repeat the title of a 
person rather than using a pronoun/ if there's no other 
way, use he/she or him/her. 

• Use plain language: Use short sentences predominantly and 

plain one- and two-syllable words whenever possible. 

• Eliminate unnecessary words: Avoid noun clusters (use 

classroom instead of structured learning environment) / 
avoid prepositional phrases (use because instead of as a 
result of) / avoid redundancies (use repeat instead of 
repeat again) / avoid wordy phrases (use truth instead of 
plain, unvarnished truth) . 

• Use active verbs: Active verbs make your style forceful 

and direct/ passive verbs weaken your language and makes 
it seem vague and lacking in authority. 

• Choose the proper tense: Use the present tense most of 

the time/ it's easy to try to use the future tense, which 
weakens your writing (e.g.. To write a program... instead 
of If you're going to write a program...) . 



D. AUDIENCE ANALYSIS 

The IEEE Standard for Software User Documentation [IEEE 
Std 1063-1987, 1988] prescribes that a software user document 
shall be keyed to its audience because the identified audience 
dictates the document presentation style and level of detail. 
The intended audience is to be identified and the different 
ways the users interact with software are to be considered 
when preparing user documents. 

Williams and Beason [1991] offered an audience profile 
description list which was useful in analyzing the anticipated 
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users of the user's guides being prepared for this study. The 
elements included were: 

• Level of computer expertise: The range for this audience 

varied immensely, with experience extending from the 
novice to the dedicated computer user to those with both 
job experience and baccalaureate degrees in the computer 
field. Few are expected to have had experience on a 
network . 

• Occupation: Students in the AS Department at the Naval 

Postgraduate School who are pursuing advanced degrees in 
the administrative, managerial science, or information 
systems area. Most have been trained in some technical or 
managerial field in which they have been working for a 
number of years. 

• Knowledge about the field and subject: Although many have 

at least an idea of what word processing is about and have 
even used such programs previously, most potential users 
of the guide are presumed to have little experience with 
WordPerfect 5.1. Most potential users have not had any 
experience with a database management system or, 
specifically, dBase IV 1.1. 

• Position in organization or field: The prospective 

audience is students and faculty at an academic 
institution (NPS) . 

• Level of education: The prospective users have at least 

a baccalaureate degree. 

• Age group: The students who will use the guides are older 

than average for graduate students, but a variation in age 
from mid-twenties to mid-forties is expected. 

• Reasons for using the program: Students are expected to 

use the WordPerfect program to create reports and research 
papers; in some cases, to complete an introductory course 
in WordPerfect 5.1; and to use the program in a variety of 
courses. They are expected to use dBase IV for 
introductory courses in database management and dBase IV. 



As the students progress in their curriculums and become 
more familiar with the applications programs, especially 
WordPerfect, they will "grow" from novice (or wherever they 
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started on the scale of experience with the programs) to 
intermediate users who then become experienced users and so 
on. Thus, what pleases them in the beginning may not always 
please them six months down the road. Also, as they progress, 
the more experienced users are graduating and leaving, and new 
students are arriving. Thus, a varied audience is guaranteed. 
No single user's guide will be able to fill every student's 
needs . 
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IV. THE SOFTWARE USER DOCUMENTATION TEST PLAN 



A. TEST PURPOSE 

The best type of review of a user manual comes from the 
users themselves. This step is referred to as field testing 
by Brockmann [1990] and usability testing by Williams and 
Beason [1991] . In field or usability testing, the users of 
the documentation try using a document to see if it is 
effective and can stand alone. Testing helps provide 
information on how to improve the document before it is 
completed. Changes can then be made and the guide retested 
before the completed version is released. This has long been 
a standard method of testing computer systems and programs. 

B . TEST OBJECTIVES 

The main objective is to identify problem areas in the 
manual while it is still in the development stage. Usability 
testing is designed to help find problems in the manual's 
wording, flow, and layout. It should indicate whether the 
writing style used in the manual can be understood by the 
intended audience, help identify steps that may have been 
inadvertently left out, and point out descriptions that do not 
match tasks. The testing can also provide information from 
test subjects on what areas they would like to see covered in 
the guide . 
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C. TEST PLAN 



This researcher followed six steps in planning the 
usability test [Williams and Beason, 1991] and [Brockmann, 
1990] : 

• Step 1. Find volunteers who match your audience profile. 
If this is not possible, simulation of a typical audience 
is acceptable. 

• Step 2. Write an instruction sheet, listing simple tasks 
for the testing subjects to perform/ the tasks should use 
basic and representative functions of the software. 

• Step 3. Decide on a reasonable length of time to give the 
volunteers to complete each exercise. 

• Step 4 . Choose observers and brief them about your test 
purpose, their role, and so on. 

• Step 5. Make arrangements for the use of work areas for 
the day of the usability test. Make sure they'll be 
properly equipped, not only with the relevant computer and 
software but also with adequate lighting and desktop or 
table space. 

• Step 6. Prepare copies of the documentation that include 
a table of contents and an index. 

After the test, results should be compared among the test 

administrator and observers to see which areas consistently 

caused confusion among the volunteers and which areas caused 

the greatest degree of frustration. 



D. TEST ADMINISTRATION AND PROCEDURES 

The tests were carried out using the preceding plan, as 
follows : 

• Step 1. A total of seven NPS students were used to test 
the documents. They were tested individually or in a 
group of three. 
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• Step 2. For the WordPerfect guide, a short letter was 
invented for the testing subjects to type in a document, 
save, retrieve, and print. For the dBase IV guide, a 
short database of names, addresses, and phone numbers was 
provided so the subjects could build a database structure, 
index it by last name, query it, and generate a quick 
report . 

• Step 3. The WordPerfect test was expected to take 
approximately one hour and the dBase IV test twice that. 
In fact, the WordPerfect test required one hour and ten 
minutes while the dBase IV test was completed in one hour 
and forty-five minutes. 

• Step 4. One observer was used. This observer was an NPS 
student who served as a network laboratory assistant for 
the AS/ IS Computer Labs and who also wrote a software user 
document for one of the applications installed on the 
AS /IS networks . 

• Step 5. The tests were conducted in one of the AS/IS 
Computer Labs, on the Token Ring network in 1-224. All 
resources needed for the testing (computers, printers, 
programs, desks, etc.) were already set up. The tests 
were conducted on two consecutive weekends when the labs 
were available and mostly empty. 

• Step 6. Sufficient copies of the user's guides were 
available for each testing subject. 



E. RESULTS AND FINDINGS 

The results of the usability tests focused primarily on 
the user's guides' usefulness, success, and shortcomings. The 
primary benefit of the tests were in the improvements to the 
document. Participants identified the following types of 
errors : 

• typographical errors 

• factual mistakes 

• confusing layout and format 
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Improvements to the manual were indeed beneficial. The tests 
helped to refine the design of poorly composed sections of the 
user's guides. After observing the subjects and receiving 
their remarks upon completion of each of the tests, the guides 
were corrected and reformatted. 

The information gathered as a result of the testing does 
not signify conclusive results due to "lack of rigor of the 
test methodology." [Zirinsky, 1986] However, the information 
was extremely useful in guiding the revision of the document 
design. The user's guides presented in Appendixes B and C are 
only prototypes and can be further refined, but can be used 
not to communicate with users at most levels of the audience 
continuum. Expert users of WordPerfect and dBase IV would 
probably find the user's guides least useful. 
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V. CONCLUSION 



In concluding the results of this study, it appears that 
this researcher's intention to create user-friendly user's 
guides was achieved. The iterative methodology of the project 
development allowed the evaluation and refinement process to 
uncover errors and unclear sections. Changes were made that 
improved the manuals and helped make them viable tools for 
teaching and for reference. 

The emphasis shifted during the study from creating guides 
that the writer thought was relevant, to creating a guide that 
revolved around user tasks. Successful documentation requires 
an ongoing dialogue between the documentation developer and 
the users. 

Much of the difficulty people experience in learning a new 
computer system can be directly attributable to poor design. 
The egocentric style of designers must yield to humility, and 
designs adjusted to accommodate the users' skills, desires, 
and orientation. [ Schneiderman, 1986] Designers need to 
understand that their design efforts may not always produce 
the desired effects for a particular audience, and be flexible 
enough to accept redesigning a system when necessary. The 
techniques for producing quality documentation will be of no 
use unless audience analysis is given high priority. 
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The ultimate test of the user' s guides will be in the 
computer labs themselves and the classes in which they will be 
used. Refinements may still be required, corrections may have 
to be made, and more material may have to be added. 
Additionally, no computer program remains static for long, and 
trying to document the software has been likened to trying to 
change a tire on a speeding car. When new versions of the 
programs are released, new versions of the documentation will 
be required. To ensure consistency within the user's guides 
appended to this paper and among any future user' s guides or 
lab manuals developed for the AS/IS Computer Labs, this 
researcher provided specifications, special graphics, and 
pertinent instructions with the AS/IS Computer Labs manager. 

In conclusion, it can be said that the principles 
described and the findings noted in this study can be used by 
all documentation writers to improve their documentation. The 
benefits gained from the testing and reviewing of software 
documentation is a better understanding of user capabilities 
and improvements in design strategy. With the goals of the 
user clearly in focus, the production of higher quality, 
useful documentation can be achieved. The ultimate result is, 
however, in the acceptance and use of the user' s guides by the 
people for whom it was designed. 
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APPENDIX A: 



AS/IS Computer Labs Software Directory 



57 



AS/ IS COMPUTER LABS SOFTWARE DIRECTORY 



ROOM NUMBER: 




1-224 


1-224 


1-250 


1-158 


NETWORK VENDOR & 




IBM 








PROTOCOL : 




IBM 




ETHERNET 


IBM 






TOKEN 


3COM 


BROADBND 


TOKEN 


APPLICATION SOFTWARE 


Version 


RING 


ETHERNET 


(PC NET) 


RING 


Hayes SMARTCOM II 


2 . 1 


X 




X 


X 


SIMPC 


2.1 (c) 


X 




X 


X 


IBM PC 3270 Emulation 


3.03 


TNI 2 , 15 












23, 26-3 


1 


X 




WordPerfect 


5.1 


X 




X 


X 


WordPerfect 


5.0 


X 




X 


X 


WordPerfect 


4.2 








X 


PeachText 5000 


2.10 




X 






LOTUS 1-2-3 


2.01 


X 




X 


X 


STATGRAPHICS 


2.6 




X 






dBASE I 11+ 






X 






dBASE Administrator 


1.1 




X 






dBASE IV 


1.0 


X 


X 






dBASE IV 


1 . 1 


X 








INGRES /DBMS 


5 . 0/02a 


X 


X 






INGRES TUTOR 






X 






EZ RATE Tariff 500-H 








X 




Annualized Cost-of- 












Leaving Model (OSD) 


1.0 


X 




X 




Universal Knowledge 












Management System 


2.00.00 




X 






IBM Storyboard Plus 


1 . 01 




X 






EtherMail 


2.4 




X 






EtherMenu 


2.5 (c) 




X 






Microtek Int'l EyeStar 


1 . 35 


TN25 








IBM Virus Scanning Pgm 


1.0 


X 


X 






Polaroid Palette 












P SAVER 


o 

• 

CM 








X 


Polaroid Palette for 










TN 


IBM PCs 


3.1 








22M 


1DIR 


3.50 


X 


X 


X 


X 


Force Analysis 












Simulation Model (FASM) 


9.9 






X 




Assembly 


X 










BASIC 


X 










C (Lattice) 


X 










Turbo PASCAL 


4.0 


X 








Framework 


X 










GRAMMATIK II 


X 










Norton Utilities 


X 










SYSTEM SOFTWARE 












IBM DOS 


3.2 




X 






IBM DOS 


3.3 


X 




X 


X 


IBM PC LAN O/S 


1.20 


X 




X 


X 


3COM Etherseries 


2.4 




X 
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A Basic User's Guide 

For use on the 

Administrative Sciences/Information Systems 
(AS/ IS) Computer Laboratories in 
1-158, 1-224, and 1-250 

September 1991 

A c&P Product 



60 



Table of Contents 



Introduction to Local Area Networks 2 

Starting WordPerfect 4 

Help 5 

Retrieving a Document 5 

Creating a WordPerfect Document 6 

Moving the Cursor 6 

Inserting Text into Your Document 7 

Deleting Text 7 

Undeleting Text 8 

Using the Typeover Feature 8 

Function Keys 8 

Alphabetical Listing 8 

Sequential F-Key Listing 11 

Block Operations 12 

Printing and Viewing a Document 13 

Printing 13 

Viewing 14 

Saving a Document 14 

Saving without Exiting 15 

Saving and Exiting WordPerfect / Clearing the Screen 15 

Bibliography 17 

Index 18 



61 



ntroduction to Local Area Networks 



I 



A local area network (LAN) is a group of microcomputers or other workstation devices located in the 
same general area and connected by a common cable. A LAN is designed to interconnect microcomputers, 
terminals, minicomputers, and other hardware, for the purpose of communicating among themselves and 
alternately with a host mainframe computer or public network. 

The most common reason for developing a LAN is resource sharing. Networks allow the sharing of 
peripheral devices such as hard drives, printers, and scanners. Application programs such as spreadsheets, 
word processing, and communication packages can be shared so that multiple copies are not necessary. 
Databases can also be shared in such a way that multiple microcomputers can have access to a single 
database. This capacity for sharing hardware and software resources allows greater flexibility and cost 
savings in the use of expensive computer peripherals and software. 

The basic components of a LAN are the server computer, the user computer(s), and the interconnecting 
cabling system. The server is usually a microcomputer that is specifically designated to act as the network 
server. The server performs only those functions required of a network server; it can only be accessed by 
users through their user computers. Server functions include repository of software programs, network 
management, printer and other peripheral device management, and database repository. 

The user computer is normally a microcomputer or terminal, and is connected to the server by a cabling 
system. A simplified schematic of a typical connection is shown in Figure 1. One server can support more 
than one user computer, usually six to ten. The cabling system connecting the server and the users can be 



PHONE LINE 




USER PRINTER 



Figure 1 : LAN Schematic 



present in a number of forms and configurations. Cabling can be twisted pair wire, coaxial cable, and fiber 
optic cable. Configurations include bus, ring, and star. 
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Logging on to a LAN as a user gives access to all the software on the server. When a software package 
is chosen, a copy of the software is downloaded to the user computer for execution. The user computer 
executes the software like a standalone computer, not accessing the server again unless a peripheral device, 
such as a printer, is needed. Further information on these and other local area network topics can be found 
in the references listed below. 



Suggested References 

Berry, Paul, Operating the IBM PC Networks, Sybex, Inc., 1986. 

Fitzgerald, J., Business Data Communications. John Wiley and Sons, Inc., 1990. 

Madron, Thomas W., Local Area Networks: The Second Generation. John Wiley and Sons, 1988. 
Schatt, S., Understanding Local Area Networks, Howard W. Sams and Company, 1990. 
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This guide is primarily for those of you who are either new to WordPerfect and/or are new to working on 
a network and need to get WordPerfect running so you can create that first document. If you have used 
WordPerfect, or any other word processor, you are used to running the program from the subdirectory where 
the program files are stored. On a network the procedure is different. The program files are stored on the 
file server, where they are shared by other network users. If every network user stored document files in the 
WordPerfect subdirectory on the file server, it would be difficult to figure out which file belonged to which user 
and extremely difficult to locate files. Thus, users cannot edit, delete, or save files in the WordPerfect 
subdirectory; they need to save files to a floppy diskette. 

WordPerfect is a text-oriented word processor, which means that as you create and edit your document, 
it appears on your screen as ASCII-coded characters (to see your document as it will be printed, you can 
select the WordPerfect View document feature. As soon as you boot up the system and select the WP51 
start-up command from the menu, an initial WordPerfect start-up screen appears briefly. After that initial 
start-up screen, you will be presented with the document screen. On it, a default status line indicates the 
document window you are in (in WordPerfect, you can work on two documents at the same time) as well as 
the current page, line, and horizontal cursor position. The cursor always starts out in the upper-left corner. 
WordPerfect always starts you off in document 1 on page 1, and with top, bottom, left, and right margins of 
1 inch. You issue commands to WordPerfect by pressing the function keys at the top (or left) of your 
keyboard, either alone or in combination with the <Ctrl>, <Shift>, and <Alt> keys. To see the formatting 
codes that are being used in your document, you press Reveal Codes (<Alt-F3>). You close this Reveal 
Codes window by pressing <Alt-F3> again. (Note: <Alt-F3> is also an example of a combination keystroke. 
It is done by first pressing the <Alt> key and, while the <Alt> key is held down, pressing the <F3> key. All 
combination keystrokes are done in this manner.) 




tarting WordPerfect 



1. Turn on your computer and log onto the network (follow the instructions provided 
at your computer). You will see, for the various applications available on the network, the 
1DIR menu with the batch file listings (files with .BAT extensions, that execute application 
programs). 
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2. Using the Arrow-Down key, move the select bar to the WP51.BAT file and press 
the <ENTER> (also called the <Return>) key. (NOTE: In 1-250, you must have a 
formatted disk to insert in Drive A: before you can access WordPerfect. In 1-224, 
you may use WordPerfect without your own disk; your work will be stored on 
C:\DATA (Drive C: in the DATA subdirectory). However, you will want to copy your 
work onto your floppy disk to keep with you since the flies on the C: drive may be 
deleted at any time.) 

3. The WordPerfect document screen then appears. It is a blank screen except for 
the status information noted earlier); it is as if you were looking at a blank sheet of paper 
in a typewriter. 




elp 



WordPerfect’s online help is available any time you are working with the program. 



1. To get help about the use of a particular function key or keystroke combination, 
press <F3> (Help) and then press the key or keystroke combination to begin viewing the 
information. 



2. To get help about a particular feature/command by name, press <F3> followed by 
the initial letter of the feature/command name (such as <S> to get help on Search). 
When a letter has more entries than will fit on one screen, type the letter again to display 
another screen of entries. After locating the name of the feature on the Help screen, 
press the function keys indicated under the keystrokes column to obtain information about 
the feature’s use. 

3. WordPerfect’s Help system is context sensitive, so when you are using a particular 
function, you can get more information about it by pressing <F3>. 

4. To display a diagram of the function key assignments for WordPerfect, press <F3> 
twice. A template of WordPerfect’s function keys (Enhanced Layout) will appear on your 
screen. Press <1> and the IBM PC/XT (IBM Layout) will be displayed. 

5. Press the <ENTER> key or <Space Bar> to exit the Help system. 




etrieving a Document 



1. To start a new document, just begin typing in the document screen you are 
presented with at start-up. 

2. To retrieve a document from a floppy disk: 
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a. Press Retrieve <Shift-F10>, 

b. Type in the drive, path, and document name (e.g., 

A:\work\document.doc), and 

c. Press <ENTER>. 

3. If you do not remember the name of your document: 

a. Press <F5> (List Files), 

b. Type the appropriate drive and path (e.g., A:\work\*.*) to see the files in your 
work subdirectory on floppy Drive A:, 

c. Highlight your document by using the arrow keys to move the cursor bar, and 

d. Select the Retrieve option (type <l> or <R>). 

4. List Files <F5> gives you an alphabetical listing of all files in the current or 
specified directory and allows you to perform common maintenance tasks: copy, delete, 
move, rename, print, and find. 

5. If you retrieve a document while you are working on another document, you will see 
the prompt Retrieve into current document?No(Yes). If you type <Y>, the document will 
be retrieved into the current cursor position in the document that is already on the screen. 




resting a WordPerfect Document 



You can begin work immediately when you have the WordPerfect screen 
displayed on your monitor. You do not have to press <ENTER> at the end of each line 
since WordPerfect automatically word wraps for you. You do need to press <ENTER> 
at the end of each paragraph. 



Moving the Cursor 

The cursor is normally a small, flashing underscore that indicates the position of each 
character you type to the screen. If you want to edit some text, you have to move the 
cursor to the desired location in the document. 



1. The four arrow keys on the right of the keyboard are the cursor movement keys. 
These arrow keys are collocated with the numbered keys on the numeric keypad. Press 
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the <Arrow-Up> key to move one line at a time up the page; the <Arrow-Down> key to 
move down one line, the <Arrow-Left> key to move left one character at a time, and the 
<Arrow-Right> key to move right one character. If you press a key down and hold it, the 
cursor will move continuously in the direction of the arrow. 

2. To move the cursor one WORD at a time, press the <Ctrl> key and hold it down 
while you press the <Arrow-Left> key or the <Arrow-Rlght> key. Holding the <Ctrl> key 
down while pressing the <Arrow-Up> or <Arrow-Down> key will move the cursor to the 
beginning of the previous or next PARAGRAPH, respectively. 

3. The <Page-Up> and <Page-Down> keys will move you to the beginning of the 
previous or the next PAGE, respectively. 

4. The Minus key <-> on the right side of your keyboard adjacent to the numeric 
keypad moves the cursor to the top of the SCREEN and the Plus key <+> next to the 
numeric keypad moves the cursor to the bottom of the SCREEN. 

5. Other cursor movement techniques are as follows: 



To Move 

To the beginning of a line 
To the left edge of screen 
To the end of a line 
To cursor’s prior position 
To the top of the page 



<Kev Sequence> 

Home, Home, Arrow-Left 
Home, Arrow-Left 
End; or Home, Arrow-Right 
Ctrl-Home, Ctrl-Home 
Ctrl-Home, Arrow-Up 
Ctrl-Home, Arrow-Down 



To the bottom of the page 
To a specified page (Go To) Ctrl-Home, {page number}, ENTER 
To the top of the document Home, Home, Arrow-Up 
To the end of the document Home, Home, Arrow-Down 
Inserting Text into Your Document 

Editing a document often requires adding new text. WordPerfect starts off in the 
default Insert mode. (If you see the word Typeover in the lower-left corner of your 
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screen, press the Insert <lns> Key located on the right side of your Keyboard to return 
to the Insert mode.) 

1. Position the cursor at the spot where you want to insert text. 

2. Press the <Arrow-Down> Key and WordPerfect will adjust the text to the correct 
margins. 

Deleting Text 

WordPerfect has many ways of deleting text, many of which are defined here: 

To Delete <Kev Sequence> 

Character by character Backspace (deletes to left of cursor); 

Delete <Del> (deletes character or space the cursor is on). 



Word by word 
Several words 

From the left of the cursor 
to the beginning of a word 

From the cursor right to the 
end of a word (including the 
ending space) 

To the end of a line 

To the end of a page 

A sentence 

A paragraph 

A page 

Undeleting Text 



Ctrl-Backspace 

Escape <Esc> n (n = number of words to the left of the 
cursor) Ctrl-Backspace 

Home, Backspace 
Home, Del 

Ctrl-End 
Ctrl-PgDn 
Ctrl-F4, S, D 
Ctrl-F4, P, D 
Ctrl-F4, A, D 
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WordPerfect 5.1 can restore any of the last three deletions at the cursor’s position. 
If WordPerfect is not carrying out a command, the Cancel key <F1> functions as the 
Undelete key. The following prompt appears along with the most recently deleted text: 
Undelete: 1 Restore; 2 Previous Deletion: 0 
Choosing Restore <1> or <R> restores the displayed text to your document; choosing 
Previous Deletion <2> or <P> displays the text that was deleted prior to that deletion. 
The last three deletions can be displayed and restored. After the third most recently 
deleted text is displayed, selecting Previous Deletion displays the first deletion again. 
Selecting Restore restores the displayed deletion to your document. 

\Jsing_ the Tvoeover Feature 

With the Typeover feature, you can enter replace existing text without pushing the rest 
of the sentence to the right. Press the Insert <lns> key until the Typeover prompt 
appears in the lower-left corner of your screen. The Insert mode is now off. 



unction Keys 



The function keys are listed here alphabetically and sequentially by F-key. 
Alphabetical Listinp 


Function 


<Kev Seauence> 


Brief Description 


Block 


Alt-F4 


Defines a block of text on which you can 
then perform any number of operations. 


Bold 


F6 


Prints selected text in boldface or doublestrike. 


Cancel/ 

Undelete 


FI 


Terminates almost any command being carried out/ 
Restores up to three previous deletions. 


Center 


Shift-F6 


Centers text on a line between left & right margins. 


Columns/ 

Tables 


Alt-F7 


Format your text using columns/create tables. 


Date/ 

Outline 


Shlft-F5 


Inserts the current date as text or code/create an 
outline of your document. 


End Field 


F9 


End of field code in a record (used in merging) 
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Exit 


F7 


Quits WordPerfect or current screen. 


Flush Right 


Alt-F6 


Aligns your text flush with the right margin setting. 


Font 


Ctrl-F8 


Allows you to change the size or appearance of the 
current fonts used in your document. 


Footnote 


Ctrl-F7 


Allows you to add footnotes that appear at the bottom 
of the page or endnotes that appear at a place of your 
choice in the document. 


Format 


Shift-F8 


Controls most aspects of the document format using 4 
submenus: Line, Page, Document, and Other. Used to 
set margins. 


GoTo 


Ctrl-Home 


Moves the cursor to a specific character, page, or 
text column, or to the previous cursor position. 


Graphics 


Alt-F9 


Allows you to combine graphics created by other 
programs with the text of your document or to draw 
rules (lines) in the document. 


Hard Page 


Ctrl-ENTER 


Ends a page at the discretion of the user. 


Help 


F3 


Gives you on-line help about a function key, function, 
or a WordPerfect command. 


Indent 


F4 


Sets a temporary left margin and aligns all text to 
this indent until you press <ENTER>. 


Indent 


Shlft-F4 


Sets temporary left and right margins and aligns all 
text to these indents until you press <ENTER>. 


List 


F5 


Displays an alphabetical listing of all files 
in the current directory; allows common 
maintenance tasks: retrieve, delete, 
move/rename, print, copy, text in, and look 


Macro 


Alt-FlO 


Executes a defined macro. 


Macro 

Define 


Ctrl-FlO 


Defines a macro (begins recording keystrokes which 
can be replayed any time). 
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Margin 

Release 



Mark Text 

Merge 

Codes 

Merge/Sort 

Move 

Print 

Replace 

Retrieve 

Reveal 

Codes 

Save 

Screen 

Search 

Search 



Shift-Tab 

Alt-F5 

Shift-F9 

Ctrl-F9 

Ctrl-F4 

Shift-F7 

Alt-F2 

Shift-FlO 

Alt-F3 

F10 

Ctrl-F3 

F2 

Shift-F2 



Moves the cursor one tab stop to the left. 

Compares documents, removes redline markings and 
strikeout text, and creates automatic references, 
master documents, indexes, lists, tables of 
authorities, and tables of contents. 

Designates a field from the secondary file to be 
merged in the primary file. 

Performs a merge of data stored in lists in a 
secondary document into the appropriate places in a 
primary document. 

Allows you to move, copy, or delete a sentence, 
paragraph, or page. You can then move to another 
place in the document and retrieve the text. 

Allows you to print a document or page. Also allows 
other functions, such as view document. 

Allows you to select any sequence of characters or 
codes and globally change it to something else. 

Retrieves a document on disk or the last text that was 
cut or copied. 

Splits the screen and allows you to see the hidden 
codes, which instruct the printer on how to format text 
and graphics in the document. 

Saves a document on disk under the name you assign. 

Allows you to draw straight lines and boxes in the 
document, turn off/on automatic screen writing, and 
split the document screen into two windows. 

Locates the next occurrence in the document of 
specified text or formatting codes. 

Performs a backward (reverse) search. 
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Setup 


Shift-FI 


Allows you to change many of WordPerfect’s default 
settings. 


Shell 


Ctrl-FI 


Allows you to exit temporarily to DOS. 


Spell 


Ctrl-F2 


Allows you to check the spelling of a word, a block of 
text, or an entire document. 


Style 


Alt-F8 


Allows you to store sets of formatting commands that 
can be applied to various parts of your document. 


Switch 


Shift-F3 


Converts defined block to all UPPERCASE or all 
lowercase letters. Switches between the Doc 1 and 
Doc 2 editing screens. 


Tab Align 


Ctrl-F6 


Aligns text on or around the next tab stop using the 
decimal/align character. 


Text In/Out 


Ctrl-F5 


Allows you to retrieve a DOS text (ASCII) file into 
WordPerfect; to save a document as a DOS text or 
other formats (such as previous versions of 
WordPerfect); to create document comments; and to 
assign passwords to documents. 


Thesaurus 


Alt-FI 


Allows you to look for synonyms for any word in the 
text of your document. 


Underline 


F8 


Begins underlined text or underscores selected 
portions of text. 



Sequential F-Kev Ustinq 



FI 

^httttttt'kI 



F2 

trfITTTITTTftJ 



<Kev> 


<Alt> 


<Shift> 


<Ctrl> 


Cancel 


Thesaurus 


Setup 


GoTo DOS 


>Search 


Replace 


<Search 


Spell 
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Help 



Reveal Codes Switch 



Screen 






/fmmiirk 





F8 

kfTTTTTTTTTNJ 





>lndent 



List 



Bold 



Exit 



Underline 



End Field 



Save 



Block >lndent< Move 



Mark Text Date/Outline Text In/Out 



Flush Right Center Tab Align 



Columns/Table Print Footnote 



Style Format Font 



Graphics Merge Codes Merge/Sort 



Macro Retrieve Macro Define 




lock Operations 



The Block command <Alt-F4> is used to highlight (mark) a section of text for use 
with other WordPerfect commands. To mark a block of text: 



1. Position the cursor at the beginning of the block and press Block (<Alt-F4:«). The 
message Block on begins blinking at the bottom-left of your screen. 
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2. Position the cursor at the end of the block (as you move the cursor, the included 
text will be highlighted), then press Block (<Alt-F4>) again. 

3. Select the operation you want applied to the block. You can choose from the menu 
items at the bottom of the screen or use a function key or combination of function keys, 
as summarized below: 



<Kev Seauence> 


Action with Block On 


FI (Cancel) 


Cancel block 


Alt-F2 (Replace) 


Replaces in block 


Ctrl-F2 (Spell) 


Checks block 


Shlft-F3 (Switch) 


Changes block to all uppercase or lowercase 


Ctrl-F4 (Move) 


Cuts, copies, or moves block; Cuts/copies column or 
rectangle 


Alt-F5(Mark Text) 


Marks for ToC, list, index, paragraph numbering 


F6 (Bold) 


Bolds block 


Alt-F6 (Flush 
Right) 


Moves block flush with right margin 


Shlft-F6 (Center) 


Centers block 


Shift-F7 (Print) 


Prints block 


F8 (Underline) 


Underlines block 


Shift-F8 (Format) 


Protects block 


Ctrl-F9 (Merge/ 
Sort) 


Sorts block 


F10 (Save) 


Saves block in a new file 



rinting and Viewing a Document 
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